Generally, a database view is a virtual or logical database table composed of the result set of a pre-compiled query. A view provides limited access to only portions of database tables that are relevant to an application. Typically, database views achieve schema independence by allowing certain physical database changes to occur while keeping the logical view interface unchanged.
Views are usually virtual meaning that their instance data is completely defined by applying the view query on base tables. Due to this virtual nature, view updates need to be translated to updates on base tables in a way that the view state after the update is the same if the update was applied to a materialized view (i.e., a physical copy of a view that is stored or maintained).
The prior art has shown the difficulty of translating view updates in a side-effect free manner. For example, as described in the publication On the Correct Translation of Update Operations on Relational Views, ACM TODS, 8(3):381-416, 1982, which is incorporated herein by reference, Dayal and Bernstein disclose generating translations for view updates. The views disclosed in Bernstein, however, are restricted to those without join attributes in the view interface. Similarly, as described in Update Semantics of Relational Views, ACM TODS, 6(4):557-575, December 1981, which is incorporated herein by reference, Bancilhon and Spyratos disclose using a view complement to determine the existence of unique translations. Computation of the view complement, however, has been shown to be NP-Complete (See S. Cosmadakis and C. Papadimittiou, Updates of Relational Views, In PODS, page 317, March 1983, which is incorporated herein by reference).
Accordingly, there is a need to achieve side-effect free translations for various types of view updates. Furthermore, there is a need to translate a view deletion in a manner that does not affect the instance of any other subview (e.g., a sub-query of a view) defined for the view.